Migo商城2.0 业务逻辑中添加redis 缓存(2) 二十
业务逻辑中添加缓存
缓存应该添加到服务层。
添加缓存不能影响正常的业务逻辑
因为之前没有添加带过期的set 方法,故需要在此再提下:
SETEX key seconds value
将值 value
关联到 key
,并将 key
的生存时间设为 seconds
(以秒为单位)。
如果 key
已经存在, SETEX 命令将覆写旧值。
这个命令类似于以下两个命令:
1 | SET key value |
不同之处是, SETEX 是一个原子性(atomic
)操作,关联值和设置生存时间两个动作会在同一时间内完成,该命令在 Redis 用作缓存时,非常实用。
可用版本:
= 2.0.0
时间复杂度:
O(1)
返回值:
设置成功时返回 OK 。当 seconds 参数不合法时,返回一个错误。
1 | # 在 key 不存在时进行 SETEX |
所以common工程中的实现为:
单机版:
1 |
|
集群版
1 |
|
后台管理系统添加缓存代码:
这里只修改一个类做下演示,毕竟只是个Demo,得抓紧时间了 :
1 | package com.migo.service; |
测试结果:
前端系统添加缓存:
前台门户系统添加缓存后,降低到后台系统的访问量,直接就优化了性能,也提高了用户体验度,这里拿大广告位服务
做例子
1 | package com.migo.portal.service; |
运行测试(成功拿到):
前后数据不同步问题解决:
这样就出现了一个问题,后台商品或者其他数据修改后,前台门户系统会出现缓存不一致的情况,这样我们可以做一个临时的解决方案,就是portal
系统可以提供一个对外服务,供后台管理系统调用,假如数据修改,调用服务通知portal
系统删除缓存中的相应数据即可
后面会通过rabbitMQ
来进一步解决此问题